 Welcome for the three please. So good morning. Good morning. I run an EA team. Our EA team does essentially two things. We deliver EA enterprise architecture work for our customers. Second thing we do is develop teams. And what we're going to do today is talk mostly about developing a team of architects. And teams and architects go together. Development and architects go together. And generational and succession planning go together. How do you get the team you need to move forward? I'm going to start one thing by talking about enterprise architecture because there's a recurrent challenge I run into is people don't assume enterprise architecture is a role. They don't assume it's a job. They don't assume it's a career. They assume it's a measure of seniority. I don't assume it's a measure of seniority. If you read one of the open group publications, the governor's guide, it's got a section in it where it talks about roles in governing enterprise architecture. And it makes a very strong distinction between a subject matter expert and an architect. A subject matter expert is somebody who knows a great deal about a subject, who knows something and is able to move forward and describe that in detail. We often assume subject matter experts are required to do architecture. That's where we get into the trap and the fallacy of seniority. Enterprise architects have a different job. Knowing what our stakeholders are want in the future. Balancing a set of competing priorities and balancing competing input from competing subject matter experts. It's an important element. We'll go to the next one, Rami. So new architects. I want you to imagine something as we're going through this. Imagine you had a best practice team. Imagine you were able to seamlessly lever in together architects, subject matter experts and stakeholders to develop what is required. Now we're going to go through this and I'm going to challenge you because we're going to use millennials as an example. Because millennials are new. They're with us. In fact, I read the other day they now make up 50 percent of the workforce here in North America. How many of us think that brand new hires are appropriate to being architects? Anybody who's in the room, think about your very first job. Think about all the teams that you've been involved in. It's very common for us when we're setting up a team at a client to have a group of people with no prior architecture experience. But they have other experience. And that's okay. Now we'll go on to the next one, Rami, please. We're going to talk today about developing that team and developing a new architect and how do you manage this? We're going to walk our way through four steps. How do you go and acquire talent? How do you go to that great talent market in the sky and get great architects? How do you develop them? How do you assess their development? And when you've got a high functioning team, how do you structure an architecture project to take advantage of it? So we're going to do a couple of things that are different. I've got a handout for you to help you along in case you want to follow along. It's on your table. Second thing is we're going to make a transformation literally from black and white to color. Rami, could you roll the first clip, please? Hi, senior architect. Hello, Mordiel. Hi, it's nice to meet you. Very nice to meet you. Did you bring a copy of your resume? Oh, I did. It's right here. Let's see. You do know that this is an interview for an enterprise architect position? Yes, I do. So how many years experience do you have as an enterprise architect? None. Have you been on any architecture projects? Nope. Do you have any architecture certifications? I do not. Do you have any experience with any architecture tools? No. What experience do you have? Well, thanks for coming in, Miss Mordiel. Thank you. Pleasure to meet you and we will let you know. Thank you. Will someone get the HR under who is screening these resumes? Now that's one way to recruit. What are you going to get with that recruiting? You're going to get people who are subject matter experts. Are you going to build a generational team through that? We'll go on to the next one. It's a serious question. How do you hire a new architect? How do you hire somebody who's got what it takes to deliver best-in-class architecture? What are you looking for? Their prior experience doing work, their prior experience implementing IT systems, their prior experience running a marketing department. So we're going to talk about a different way to hire. I'd like to start off by talking about my actual experience with my interview with Dave to be a part of his architecture team. And it was one of the weirdest experiences of my life. He didn't ask me a single question about what I learned at college. He didn't ask me about any prior job experience. It didn't seem to matter what my experience was. I wasn't even sure he had read my resume. It didn't seem to matter. We talked about how I interacted with others. We talked about my commitment to fencing at school. What was even more interesting to me was the very first question he asked me was, do I like Italian food after already arriving to the Italian restaurant? So in retrospect, if you're hiring a millennial, if you're hiring a new architect, what are you looking for? I'm shopping for two things. Attitude and aptitude. I assume they don't know how to architect. I assume we're going to have to teach that. Attitude and aptitude become absolutely critical. Anyone ever tried to explain enterprise architecture as a profession to their mother? My mom doesn't know what I do for a living. She says I do stuff. So now explain that on your job posting. Explain that to the person coming in on the hire for the interview. Or are you going to look for aptitude? Are you going to look for attitude? Are you going to look for their ability to effectively communicate? Are you going to look for their ability to work on a team? Are you going to look at their ability to think, to lead, and communicate? So Sam, in retrospect, how did that interview play out? What was I hunting? Well, at first, it seemed like you just wanted to talk to me about my interests and things I was into. But in retrospect, you asking me about my interests and my commitments, like participating in team sports, I could tell you were looking for my ability to collaborate with others effectively. Specifically, your question around how I handle disagreements with my peers. How did they get resolved? Did I defend my ideas? Did I listen to reason? Was I able to blend my knowledge? Hear other points of views? This is critical for dealing with subject matter experts and balancing stakeholder preferences. If we were going to disagree, Dave and I, was it going to be a waste of time? Or was it going to be producing more better results? I think you were testing for my nimble thinking and being able to accept the fire hose pressure of transferable knowledge you are going to give to me in a short period of time. Oh, and it turns out liking Italian food was going to be a deal breaker. As consultants, we eat out often. Fortunately, I love Italian food, so I got the job. Unfortunately, a few weeks later, we went to a steakhouse and I ordered vegetables, so I got fired again. So in the interview, I heard the interviewer asking about technical skills. I have technical skills. I can repair helicopters, I can repair jet turbine engines, or I can non-destructively examine welds for quality and safety. When they mentioned technical skills, were those those that hopped to mind? Or did you go to information data management? Would you have hired me? Now, for transferable skills, Dave and Sam mentioned them. The three that popped to my mind are attention to detail, accountability, and analytics. For attention to detail, you can't repair a plane, leave out a bolt, and expect it to work properly. Would you fly in a plane that you knew was missing a bolt? For accountability, aircraft maintenance also has the highest standard in that field. You make a repair, you write down your name, your number, next to your repair. If anything goes wrong, accident investigators track you down and see if you're still fit to be in the industry, if it was your fault. Have you ever taken your capability model, signed your name to it, and seen if you're still fit to be employed in the industry, following a review? That is accountability. For analytics, I find keyword matching is usually a problem. You go to analytics, you immediately go to data analytics, information analytics. Why don't you change that to troubleshooting? Why don't you take that a step further and you go to problem solving? That's what you're looking for. Pilots and VP of sales will say two different things. Pilots will say the plane felt funny, it didn't fly right. VP of sales, they say we need digital transformation, or we need to improve the customer experience. That's all well and good if you know what you're doing to fix it. But since those don't have a specific answer, you step into troubleshooting. You dig, you explore, you examine, you test all your theories. But you always have to maintain, will the plane still fly when I'm done with it, and is my competitive advantage still available? Maybe the interviewer should have asked for demonstrations of relative skill of relatable techniques and skill rather than experience. Or they could have asked about Italian food. What are you looking for? Think about what your hires. That's the challenge. Are you hiring the right people? Are you hiring the people who will excel in their industry? Are you hiring attitude? Are you hiring aptitude? Are you chasing thinking skills? The ability to challenge an idea? The ability to explore an idea? Are you chasing down things that are very, very hard to see in a resume? Particularly when that resume is coming from a new graduate. What are you going to see on that resume? You're not going to see, as our film clip showed, a raft of projects, a raft of experience. And if you're chasing keyword matching, you're not going to find it. You're going to have to listen. You're going to have to have a conversation. It's going to be absolutely critical for you to walk your way through that interview in a conversation so that you can hear and explore the fitness of the candidate in terms that will matter over the next period of time. Because if they're a new hire, they don't know how to do architecture. You're going to have to introduce them to the profession. And introducing them to the profession and sustaining them through time requires us to consistently develop, to consistently move ourselves forward. At the end, I'm looking for great architecture. I'm looking for great architecture that addresses the needs of my stakeholders, that gets the organization where it wants to be. And I'm going to use the talent that I've got to get there. And critically, I don't want any bolts on the floor. Why don't we get benefits from what we're doing? I know exactly why we don't get benefits from what we're doing. Bolts on the floor. We skip things. We forget what's going on. We carry baggage into the room and we argue with our stakeholders about what they want. That's not what you get with somebody who can collaborate. That's not what you get with somebody who's a creative thinker. That's not what you get with somebody who has the right attitude and aptitude to be an architect. So let's think about how we train and develop. Romy, can you roll the next clip? Well, Millennial, I'm off to the client site to make a presentation to the CEO. I'd love to join you with that meeting. Do you mind if I come and listen in? Not this time. I don't think you're quite ready yet for senior management meetings. However, you could make sure that you get those flowers ordered from my mom. Is that the IT for IT reference architecture ringing there on your screen? Yes, it is. It's a perfect reference model for the work you're doing at the client site. I was wondering... Well, no. We don't use reference architectures here. We prefer to do architecture in our heads. So training. Training or development. Training or development. Building an architecture team. We're going to send them to a TOGAP certification course and they're good to go. Don't get me wrong. TOGAP is important. TOGAP is valuable. It's a fundamental of how we've built our practice. But teaching you about the enterprise continuum, understanding it as a concept doesn't make an architect any more than an electrician is developed by knowing the building code. What is it that you need to do? Build an apprenticeship model. Let's step back in time. How do we develop people? Build apprentices. Start them out. Work through the skills, the technique, the experience and the judgment. When we're doing our development, we're constantly hunting technique, experience, judgment. What I'm looking for is do I have the ability to do the work? Do I have the knowledge to use the process, the skills, the reference models? Now can I accelerate experience? I don't have time to wait 25 years for 25 years of experience. I need to accelerate it. And I need to create conditions of great judgment. How do I help make my new architects move forward? And importantly, through that process, how do I make sure that my experienced architects are also improved? Where are we going? What is it that we're doing? Now that apprenticeship, all good apprenticeship, is hands on. Hands on is right. My second week on the job and I'm flying out to the head office of a client. I was there surprised to find myself participating already in a scoring workshop for process improvement. It wasn't for a little while until I found out that this process model we were using was a reference model that we would be using again and again over the years. An industry standard that was simplified. That I could help instruct and explain the model to the leadership with. I even helped walk the leadership through pieces of the workshop. This turned out to be my apprenticeship model. Being in the room for every meeting. Doing something in the room. Showing value. Every meeting the seniors had that they were at, I was right there with them. Another way to gather experience quickly is to always show your work. Strong architects like Dave will hear a question and they can jump to an answer most of the time. The problem with this is it occasionally leads to just lip service to both traceability and to your stakeholders. Walking through every step ensures you actually deliver. Do you want to jump from A to D or A to Q? Walk through the steps. Confirm your intermediary steps that actually make sense. A, B, C, D. During engagement in Saudi Arabia, I was with the senior architects Dave and some others working through a capability model. They were leaping through the steps. I couldn't keep up. So the next day I had, I walked them back through the reference model that we were applying to that capability. Can you guess what we found? We found bolts all over the floor. They had missed parts. By leveraging the reference model and our technique, we were able to clean that up, find the right answers and end up with better architecture for the client. We were able to document trade-off, document traceability to the stakeholder and better yet document the difference in the trade-off decisions. We ended up with better architecture for the client. We ended up with nothing missing. No bolts on the floor. So tracing your logic. Deliberately developing. What skills, that technique, that experience, that judgment? What are you doing? Are your new architects, your millennials, your people with experience who are new into the field being brought in in a systematic way? Are they being apprentice to the trade? Is enterprise architecture for you a career or a badge of seniority? I'm really focusing on that badge of seniority because it's a recurrent challenge we run into. Oh, no. Sam can't do that work because what's the net of the reason? She's too young. So you're building a team. You're walking your way through about deliberately developing somebody, developing the technique, accelerating experience and creating conditions for judgment. Nathan explained about working with senior architects in terms of technique. Developing in terms of technique is absolutely critical. How many of us come into the industry, carry our baggage into the room and know how to do things? One of the fundamentals of building a team is that you have a common sport. Let's put a rugby player, a polo player, a soccer player and a North American football player. They're all running sports. Let's put them on the field together and have them run around. Does anyone know their role? Does anyone know their position? Can they work together seamlessly? How does your architecture team work? Do you follow a common technique? We make aggressive use of reference models and we make aggressive use of reference models because they do two things. They accelerate our work. Acceleration of the delivery of enterprise architecture is critical. What's a recurrent challenge that you hear? Oh, we can't get the architects involved. It slows everything down. It takes too long to do the architecture and we don't get there. Why does it take too long? We reinvent the wheel. And every time you reinvent the wheel if you do a good job, it's round and removable. I'd like you to reflect for a second on round and removable. How many times have you heard somebody use the phrase reinvent the wheel? It's always round. What did they leave out? You're right, it's removable. It's far more cost effective. It's cheaper. Spot weld the tire on. When you use a reference architecture, when you use good reference models, you have end to end coverage. You don't have to invent and reflect and cover everything. You don't have to remember it. I use reference models so that I can accelerate the development of my young architects, my new architects. What are the pieces that are included? Nathan had IT for IT up on the clip. What's IT for IT? It's an end to end information model for IT operations. It's got some functional components, but they're way less interesting than the black circles. So if you're ever using IT for IT, black circles. What is the complete set of information that must flow for a high functioning IT team? Do you have to now reinvent that wheel? Do you now have to remember that wheels are removable? Or do you have it there and are you looking for it so that when you're looking for the proposal component, the reference model says it exists. The reference model says it's being used. So what's your challenge as an architect? Find it. Where is your portfolio? The company's got one. Where is it? Oh, that's right. It's a collection of sticky notes. It's a collection of whiteboards. It's a collection of project plans and 300 reports from SAP. That's what that information object represents. So I can take my young architects and structure an engagement where they start walking through the model. Where are these pieces? What are the information flows as Nathan said? They can guide subject matter experts to get a better answer. They can pull information to get better architecture. And they don't show up with prejudged questions. How many times have you been frustrated to work with an enterprise architect who was carrying baggage from their previous work? They knew the answer and they were going to force fit the answer. Or are you going to listen to your employees? Are you going to guide your stakeholders to trade off? Apprenticeship plays both ways. It's good for me because I have to actually explain my work and I start to find the bolts I'm leaving on the floor. It's good for my staff because we develop consistent work and are able to move ourselves forward. We're able to develop better work as a team. This is important. We're a small group. Our architecture practice is sub 50 people and we work around the globe. We work in multiple time zones. Currently I've got a team working in Saudi Arabia being supported by a young guy who lives in the Pacific time zone. That's 12 hours apart. Let's do random work. Can you lever people in and out of the work? So let's think about how you assess development. How do you build out that team and how do you know which team members can participate in what? What's the assessment techniques? Can you roll the clip, Romy? Been here six months now. Yes, house time flies and I think we've been wearing the same clothes when we first went. Yes, I've never changed. So I've seen. How many bill of blowers you got in the last six months? Well none. How many client deliverables have you completed? Zero, of course. So I've really done the last six months then is keep me busy. Yes. Well, I've learned so much. What a waste of my time. That performance of you spoke to me on a personal level because I thought at my first performance of you that I was going to be fired after three months. The list of what I didn't know just kept getting longer and longer. I had lost track of everything I had learned. But when you think back to development, aptitude and attitude my story changes. I've always been part of best practice. I've always done formal modeling. I've always done component and relationship traceability. That's just second nature. You take an application you break it apart into functional pieces. Model the information flows and take both those pieces and information flows and bring them back to the business. You find your target for the stakeholders. How it all lines up. That's just second nature. It's what I do. It's what I've always done. I didn't realize the habit. I could only see senior architects leaping from here's your question to here's my answer just done. And I couldn't do that. But now in a recent engagement with Samantha we did a roadmap across six state agencies with independent missions and they were all sharing information. We were able to break all that work across our team and bring it back together seamlessly. No hiccups. Our approach and using a formal modeling tool allowed that. This isn't an example of each individual architect walking away from the others. Just the information architect ignoring the application architect ignoring the security architect and then bringing the work back and saying why doesn't it work. This is a team of architects. Breaking the work apart taking responsibility for their part of the architecture and bringing it back. It just fits. Sam and I can use our senior resources for point questions and for overall quality review. It's fantastic but without a consistent method consistent repository and a consistent team this isn't possible. Team development is best accomplished by playing to your team member strengths. The apprenticeship model and my team staged my development. For example leading an architecture approach is not easy. My first time leading I had two leader senior resources at handy. It was a good thing too because I needed a lot of coaching. But my team had my back. The next time I didn't need nearly as much coaching. That next time I led an initiative with client resources and some senior oversight. Don't misunderstand. This is not the typical Jedi relationship the pod of one learning from the master. A team develops different strengths and different skills at different rates and different times. Everyone teaches and everyone learns. I was able to teach my client resource technique to how to build an information model. At the same time he provided me the knowledge and the insights to guide and shape the information architecture. The same one for Nathan. He taught formal modeling at the same time learning application architecture from tree. One of our other lead senior resources. The apprenticeship model is all about setting up your team so that they don't fail. I had the seniors nearby should I need them I had a safe space to learn and try new things. I never got set up for a performance review like the one in the video. I get to walk into my performance review with several examples of how I demonstrated value. I am however expected to be self aware and learn and know the link between what I've learned what I've done and the value that I deliver to my team. So when you're staging development it works with deliberate support. Sam told us a story about leading an initiative. We very clearly identify the people who need to do the work and we have somebody who owns the initiative and moves it forward and leads it. Does it mean that they do all the work because it's a team? Does the quarterback do everything? Does the goalie do everything? Or do they play as a coordinated whole and how do you develop that experience? The very first time we had Sam lead an initiative she had two resources on it myself and Shriram. It was safe. She could crash and burn and that was okay. She learned from that initiative was able to expand onto a future initiative and most recently ran the show on initiative where she was also a key delivery resource. Consistent development How do I accelerate experience? Acceleration of experience at the team, at the practice I talk a great deal about acceleration, about why we use reference models, about why we use formal modeling tools, about why we use an apprenticeship approach. And it's about acceleration. Accelerating time to value, accelerating time to experience and providing and consistently delivering better work. Leveraging the right resources. When I've got a team I can look at how my structure is. I can look at who is required to do the work. What are the different resources? And in that development of the team the essential piece is what are they able to do that they couldn't do before. As architects we talk a great deal about capability based planning capabilities and capabilities are miracle and magical. If you're developing an EA team and you don't have a capability roadmap how credible are you to talk about somebody else's capability development? Or do you have a bolt on the floor? What's the ability development of your team? Are you able to deliver the architecture that's required? Think about Togav, jump into phase A. What's one of the very first steps in phase A? It says it's a capability assessment. What do most people immediately run to? Oh I'm going to assess the capabilities of the business. Have you ever read the text? It says assess the capability of the architecture team. Can they deliver this piece of work? Are you able to move forward? Are you able? And if you're not developing your team if you don't have a consistent approach it's much harder. So think about a real performance review. What work did I do? Or my abilities? What's the development that I've got? Focusing on growth. Collaboration. You guys ever work with a superhero architect? Superman knows everything, does everything? Only her way? Or are you trying to build an architecture that spans multiple disciplines in multiple things? Because if you've worked with the superheroes what collaboration do you have? Are you able to move forward to seamlessly bring people in? And is the learning being applied? Is that experience accelerating? Are we able to do better? And a key piece of that when you're looking for teamwork and collaboration is the ability to learn an intake and capture information from others. Why? The world is filled with subject matter experts. Subject matter experts who know a great deal about a narrow thing. And they will view the entire world from the perspective of their narrow thing. So you ever talked to a user experience person? Have they able to talk about anything other than user experience or customer experience? Or now let's talk about the accounting department. One of our clients was looking at doing some work on a digital transformation and one of the requirements that came in from accounting was clean order entry for a services company. Delivering that to break the customer experience. Who knows all that? I'm going to have to bring in a subject matter expert, listen to them, listen to their concerns, listen to their awareness, their expertise, and as an architect put together a whole that delivers. So if you have multiple engagement models with your customer is following the accounting advice of a single order entry process appropriate? Or is it inappropriate? Focus on growth of your team. And when you have a team and I wish you all that you guys could have what I've got, I have an awesome team scattered around the globe. We work together consistently consistent approach and when you have a team you're in a position to put the project in place and put people on the project to deliver what's required. Can you roll a clip about team planning, Romy? Great news everyone. We just want a two million dollar enterprise architecture contract. Each our manager. I take you further about our new enterprise architecture contract we just won. Well I'm going to need three yet senior enterprise architects by Friday. We build EA teams for a living. We build, we deliver best in class architecture for a living. Make sense to make most of the stuff repeatable. Not some of it, most of it. Predictable EA. Plan your work to deliver EA. Deliver the architecture consistently and deliver the architecture within a fixed period of time. And deliver it predictably. The result of best practice team planning ruthless repeatability consistency across your work. In my recent experience I led an effort with Nathan and another new architect with oversight of senior leaders providing review and support. How many times have your team done similar deliverables but it feels like you start over from scratch each time? Maybe you had new clients maybe you had new team members or old team members leave start with what you need. This is what we've learned. Break it down to the pieces that will when finished finalize your deliverable. Divide the work up across your team and leverage reference bottles ruthlessly every chance you have. Otherwise you are simply recreating the wheels Dave says. The wheels round and removable every single time. There's no value in recreating the basics. This enables ruthless repeatability in your team. In the future if you need to do a similar deliverable again get out your plan assign and manage the work to completion you have your predictable approach forever and you have consistency you have reusable work you speed yourself to completion the architecture will change but the process the work and now come it all stays the same. Think about what a classic deliverable of a roadmap is included. What you've got the roadmap is a series of work packages sequenced together that series of work packages are all about gaps that need to be filled where do the gaps come from the difference between the current state and the target that meets the needs of your set of stakeholders how do you develop that well let's describe the current state one way let's describe the target a different way oh I can't figure out the gap anymore what am I left to a collection of work packages of things that I think are important which ones of them line up to the capabilities we want which ones of them create efficiency which ones of them create agility what is the priority or anything on my work I don't know because I didn't keep track of it consistently I didn't have a good reference model I didn't have a solid tool behind it I wasn't keeping track of attributes it all comes to working backwards what do you need in order to deliver that roadmap what work do you have that you've already done as Simon Dave say, break it down use reference models repeatable approaches and consistent repositories don't use random power points and vizios you'll never keep track with them at my latest engagement I had to take the statement of work and use our approach of gather, analyze and then report to break it down into the necessary components I was able to use our repository to review it to review for prior work that was relevant or if there was any prior work at all the relevancy is key being able to see what applies what still applies that you don't have to redo it after that, I learned where to gather where I needed to gather more and where I could analyze after that, who goes to gather does an architect need to go gather or if I need more detail, can I send a subject matter expert to go gather it and then just build off of his knowledge architecture should always be built against your stakeholder preferences that's your goal, it's always your goal if it's not your goal who are you working for never do rework for everyone's time and should only change direction if your stakeholder changes direction because otherwise you're just leaving bolts all over the floor the result of all this consistency consistency of work, Dave mentioned we work in different time zones how is it that all our work just fits together the effort Nate and I were speaking to earlier was for an integration architecture and we asked ourselves what did we need first, we knew we needed a reference model and when we got a good one we took it with us everywhere we went second, we had our seniors take on the gather step you may assume that Padawans can do the gather step in our practice the seniors gather what's more, we don't actually have architects do the gather we have subject matter experts we leverage their specialized expertise to listen and hear the nuances of the business which then that feeds us the requirements for the analysis we observe that many architects feel they need to know everything about everything and we don't simply have time for that we leverage subject matter experts to feed us exactly what we need to know third, then we analyze the analysis is where everything comes together the information flows start to paint a picture the disparate systems that we were integrating start to appear not so disparate anymore and they share a commonality that wasn't before apparent so we brought specialist architecture resources to explore the complex pieces of the analysis with a consistent approach and a strong repository they step smoothly into their pieces of the work and finally you do tradeoff getting the architecture done requires a really detailed nuanced understanding you need excellent judgment for guiding stakeholders through the tradeoff the most experienced architects can take the core concepts and convey it to others so that it makes sense to non-architects in the end we knew we got the message right so if you need an architecture related deliverable you can break it all down what do you need who do you need to do the work first get your reference model second do your gather leverage prior work and check it for recency have your padawans supported through the analysis process and fourth we bring in our seniors to carry our flag upstream to the leadership and they get to take all the credit EA is predictable and it gets more so with each iteration that you do with your team so do you have a team do you have a collection of individuals are you leveraging the talent that is available in your organization we did an architecture project for a construction company the fundamental motivation number two they operated as 51 distinct organizations across North America this way construction companies often are there was the commercial group for this city the commercial group for that city the mechanical group for this city the mechanical group for that city average project size that they did was 50 million dollars what did they want bigger projects what does that require an ability to work together seamlessly because what they discovered when they decided well we've got all these pieces we're working on a big project we'll bring everybody together is they treated each other like subcontractors and if you've ever worked in the construction industry you are brutal to subcontractors you pass risk and cost to them at every opportunity and if you can stiff them you stiff them oh that's right we're all sharing a balance sheet how well did that work so we're architecting this who do you get to gather the basic information about what a best practice process design is what a best practice information model is subject matter experts people who worked in the field people who were out on a construction of a refinery site who understood time management with 4,000 trades workers filling out their time sheets at the end of every day by task so that we could do earned value reporting tomorrow those are the realities what do you need to bring in then to architect a team collection of individuals or Superman I find working with a team everyone wins I can develop consistently I want to stress a great deal I've come back repeatedly to the distinction between an architect and a subject matter expert every time we treat enterprise architecture as a seniority stage we've assumed subject matter expertise it's the technique where do I get the analysis how do I test the analysis and what am I looking for fundamentally what I'm looking for in an architect is understanding how the system as a whole works and how it fits together how does that system meet the needs of our stakeholders subject matter experts have a great deal of expertise and increasingly we have a modern world where our end user community are technologically savvy they're used to using technology they're used to applying systems and they've been doing it since they were in kindergarten that's a radical change in our world it's a radical change in the enablement of our business I can't stress enough that if you have subject matter experts acting as architects they can cripple you they're very bad at listening they're very good at telling so we've been talking about the future we've been talking about where we're going we've been talking about best practice architecture and been challenging hopefully some of the thinking about it we've got a recap Sam and Nate have some points they want to really drive home architecture practice is best done as a team your leader improves technique experience and judgment across your team it's the same effort for a millennial a new architect or an experienced architect it's the same effort to hire any of them and bring them into your team however there is no time saving if it's the wrong person if you bring in the wrong person and they fail to deliver that is time wasted so why did you go for old or new if they were a waste of your time hire for aptitude, attitude and transferable skills and then hold them accountable so we talked about today how you develop best practice EA teams we hired millennials we've tested it and we know it works you probably never considered hiring a millennial before but today I hope we showed you how to interview for one how to assess one and how to develop them and by the way this works with any architect of any age millennials were simply the test and we passed we know how much baggage we carry in the room when we walk into the interviewer or the performance review if Dave could develop me we can do it with anyone don't hire for the wrong team member though hire for that attitude that aptitude and those transferable skills that's the right team member and Italian food we've been trying to talk about value to you value to your organization value to your team architecture is all about creating value every one of our organizations that we work with are successful what they're looking for is to be better the practitioners individually about being better and there's things to take away is your technique repeatable is your approach repeatable can you gather information effectively as an architect do you take on board that learning communication learning the thinking skills think about your architecture team or the team that you work with or the team that consumes architecture or the pieces that need to be put in place Nathan was talking about gather analyze report it's our quick shorthand are we gathering things are we analyzing things and are we reporting things who has to show up for the different stages and that analyze piece is interesting because chunks of it I can pass off to people with limited experience chunks of it I can't it all to be consistent so that we're in a position to end to end analyze it and end to end take the pieces that we did and don't do rework rework is brutally expensive when you get a good architecture your organization can dramatically improve mention the construction company one of their single largest customers as we were working through this transformation told us well we really like your company we think you're awesome you guys do great construction we wish that the unification between you was not the same business card we deliberately cut the scope of work to you to be sub 40 million dollars projects because that's anything bigger than that and you guys can't coordinate yourselves what we were essentially hunting is larger projects have more margin six months after we started the transformation to grow that organization that customer awarded them a 1.34 billion dollar construction project to replumb a nuclear reactor based on their ability to work together effectively that's changing an organization for the better and moving ourselves forward so you can go back to your old ways and watch the film or start taking forward some good ideas it's a lot of fun working with millennials they challenge you like to thank Ken Street and Celeste for their cameo appearances in our videos and we've got a window here for questions so one of the important things as a leader of a team Silver Fox got some experience with easy questions without an obvious answer and I'd like you to direct all the really hard questions to Salmon Nate questions I get to choose who to direct the map thank you thank you all three of you you could tell from the you had the total total attention of the audience very quiet it was wonderfully done and quite thought provoking thank you very much okay first question that came in was very quickly coming in you spoke of the right attitude and aptitude for the hires of the millennials can you say a bit more about what you look for in the pairing with an apprentice so the attitude the aptitude for the more senior person in that pairing the essential piece is there's academic works that are worth having a look at both by Lincani the five dysfunctions of a team and teamwork and what he's hunting for in teamwork in particular is the attributes around trust being open to being able to be vulnerable in terms of communication personal style so Sam had joked about the Italian food for the last three years which has approximately a thousand nights I think Sam and I have had dinner together about 450 times at least so some of that is are we work compatible and are we able to team together but a lot of it is around are you in a position to teach and learn both so Nathan and Sam what do you wish you'd known when Dave hired you what I wish I knew three years ago was that what I was being asked to do weren't just tasks when I started it was to take the application break it apart map that out tie those together to the business and see how they connect to the stakeholders for me it was one, two, three now it's connected I'm done I never saw the bigger picture I should have asked how what I'm doing is affecting what else is happening in the contracts seeing the bigger picture earlier would have helped a lot for me if I could talk to myself three years ago it would be don't get discouraged about how much effort you put into a piece of work that you're just going to throw away iteration is key and sometimes the work you do that you're going to throw away is just to set the stage for other people to build upon and it looks completely different at the end okay, next one Ken Ken Street looked I'll add the word uncharacteristically the question doesn't say that Ken looked frustrated in the performance review how does a senior architect know when it's time to let go of a new architect oh that's easy I fire lots of people what we were talking about there is development so we do quarterly reviews swine eight was able to talk about quarterly review and at the beginning of every review we talk about what abilities that you're going to be working on and we line them directly up to the work that we have and the work that we have in our pipeline so I'm going to pick on Sam here one of the things that she's been working at is the ability to lead a team and coordinate a team if Sam doesn't show a progression of walking through that ability to lead I'm now wasting my time and the moment I start wasting my time on developing somebody who are not able to go forward that's when it's time I hope that answered it it sounded sufficiently ruthless oh yeah the writing's on the wall at that point okay what can I expect a millennial when can I expect a millennial to actually start doing real architecture as opposed to just supporting a senior so when were you guys expected to start delivering useful, unique work I would say right away the first thing you had me do was break apart our metamodel and really specify it get all the components and relationships that really staged my fundamental learning something as high up as a metamodel and then seeing how it trickles down to the architectures my question is did they mean useful work as in work that's able to be presented to someone or work that they can say go off and do this you don't need me to oversight I suspect it's the latter but it's not my question but I suspect it's more when you get when you're expected to be let loose for me that was definitely the second project our second project I was given basically free run over over our model where we needed to gather how it was being put in and where they needed more that was my second project so so they talked about building an integration model for a government agency here in California and on that Sam and Nathan did about 95% of the architecture the remaining 5% was a set of complex integrations between up to 400 agencies and for that we had a different architect do that because we just wanted to make sure that area had a high probability of having nuance that was unfair and unreasonable so a big piece of that as Sam said in the presentation is not being set up if you understand the work that you're asking somebody to do you're in a position to have them do work that's within their capability set now the other flip side is that I constantly ask them to do things that they can't do and that's okay because I'm not going to be the one who decides what their abilities are they're going to demonstrate it so I'll find safe environments for them to try things so that they can extend their skill set well and like you said you stress the repeatability of different architectures so you might be in at the deep end but you've got the life belts there to help save keep you above order okay sounds like this is for you Dave but there may be something that Nathan Sam can add you seem to suggest that like a little knowledge can be a dangerous thing some IT or architecture experience could actually be a disadvantage is it easier to start with a clean slate subject matter expertise is concerned we have not hired anyone into my practice with an IT background in the last four years and that was a deliberate choice what I have found repeatedly is that people with an IT background carry IT baggage and I was talking this morning at breakfast about the obsolescence of a CIO role and the obsolescence of classic IT thinking where more and more our IT need is being driven by our business and our business understands what they're trying to accomplish and the plumbing I'm not interested as a rule in trying to solve for IT problems I'm interested in using that example from the construction company we built a very very complex IT perspective integration between their scheduling tool and their time and labor tracking tool that the IT group argued with constantly and that was done to solve a business problem the other aspect of what we did is the selection of the project control software was beta software and the IT team completely said oh we can't do beta software my target our target as the architecture team was today plus six years that was our target for reaching the company we wanted to be the software implementation was today plus two years my IT team were not in touch with where we wanted to get to they weren't in touch with the scope of the transformation that was required but flipside is the project matter expert thing that we've been stressing a lot of that is what do we need to do so that we actually serve the IT organization better so that we have sustained agility so that we have sustained security and architecting for that up front a related question how would things be different if one of the people you were considering to hire and an internship under the belt the last person I hired has an MBA and did an internship at Uber in South Africa in Johannesburg so the whole approach of internship is internship and apprenticeship is working closely with us so that we can have a technical experience seamlessly back and forth I don't hold having an MBA against somebody okay, question initially for Sam and Nathan and then Dave I'm sure you have something to say about it what is your view on the role of young architects in organizations like the open group just before we got up on stage we were talking about at the open group and that there wasn't enough involvement from young people so I hope this was our attempt to call to action for senior architects who do attend the open group to bring on younger people younger architects so that they can start attending and we can see a change in that yeah for me the open group is a great place to meet people and meet new minds there's only so much you can learn when you have a sieve in his head for other people you can learn all sorts of things you can learn from the information security you can learn from I've mainly been trying to tap into the knowledge from the information security teams I find it a little fascinating the way they talk about it but you meet great people and you learn a lot of new perspectives so I'm constantly looking for education and learning opportunities we have a practice that delivers work often at a strategic or portfolio level and that isn't the sum total of all architecture so we are routinely engaging our architects on our staff in initiatives at the open group largely as a learning exercise I got maths in the background and I remember first time I worked with maths I think it was in Barcelona in 2004 I think I learned more in that weekend in Barcelona about service oriented architecture than I have learned at any other point in time that's an opportunity that is here that we don't have elsewhere and we actively engage our people in the open group for those experiences thank you two very well almost identical questions how do we retain the new talent that we've trained over the last few years because if we believe what we read millennials don't like to stay in one place they want to move around with the very closely related what's the secret to retaining a millennial so I feel like that's a very common perception about millennials is that we want to move around a lot and from my personal perspective I'm not chasing a bigger paycheck because I was offered one I was offered one but then my growth as an architect would be stopped because I stayed with Dave because he's a global thought leader in the practice and that's what is valuable to me is being able to grow rapidly and be able to be coming a good architect on these client sites and be billable and deliver good architecture and the open group is just a great place to expand outside of someone like Dave's who is a global thought leader but here different perspectives difficult and there's tremendous opportunity it's I got into the architecture form because we do architecture there's just so many domains security big data so how do we retain you Nate? for me I'm sure you've heard either you saying it to someone my age or someone you know saying it is you're still young there's still so much ahead of you don't let yourself get locked down into something you can go try new things I've said that if you've heard that then millennials flitting about is because they believe they've stopped developing where they are through the open group through Dave through traveling around all the people I've met I've never seen a stop or wanted to stop my development the open group is a good way for me to keep doing that make them believe that they are an investment to you and they will stay with you what we've developed is a very deliberate approach of value in a set and moving forward I don't think millennials are any different than any other generation if we treat them as disposable parts if we treat any of our workers as disposable parts they'll act like disposable parts they'll look for the next thing if you're providing a cohesive team if you're providing interesting work if you're providing continuous development and apparently no need for more pay raises you have retention okay how do you deal with customers who have issues with experienced architects that you have on the team I mean any of you from your experience as the less experienced architects or from Dave's point of view I don't have much experience in that I'm usually the offsite resource they just see my name and what I provide it's actually interesting because we find most clients are actually really excited to have us on and that Dave's effort to develop us is also an investment for the client that will become better architects for them in the future so typically they're really excited and they like the idea we run into it most often through supply chain and procurement where they'll have this tall and this old in order to be on this RFP the second aspect of how we deal with it is a big approach of it is the team it's we're going to approach this with the right skills in all honesty it is a challenge with about a third of our clients on day one showing up with some of the people delivering the work that we use is we talk a lot about development and at least 50% of our work is developing in house EA teams helping them be better and what we talk about is using exactly the same approach to accelerate their teams development as we use to develop our teams development so Nathan Sam how do you deal with the situation where you find that your seniors have left bolts on the floor we mock them and we look at that bolt quality review is as much for us as it is for them if they're going through our work we go through what they did they need to see if we can follow it to see if we're in a position to be either asked to shadow the next time that needs to be done or if we can just take that over so if there's a bolt on the floor that someone leaves behind we do get to tease them a little bit about it I can imagine we also want to know how the bolt got there and then we can find our gaps it's just tracing your steps most common bolts are traceability we'll have an architecture that says well we have to do this why? cause what's the reason for the cause it's what you should do cause does it have anything to do with this problem and one of the things I've observed is our new architects are far better at hearing what our clients want than our most senior architects right so do you think it's possible for a subject matter expert to become an architect oh I'm getting this one does that one sound that hard yes it is it's not impossible for a subject matter expert to be an architect but it requires them to actually become an architect a subject matter expert has deep knowledge about how one thing or a set of things are done optimally for that problem space that problem space may not be the defining problem space so you need to then address what is it that we're trying to solve for that's a phrase we use a great deal what am I solving for what set of concerns am I solving for and can I solve for a set of competing concerns okay final question I think this session was a great start how do you suggest we improve the visibility to other new architects how do we get the message out I think the call to action comes to you guys your leaders hire new architects bring them up here force them to talk like Dave does okay I think the essential piece is start by hiring them recognize that when you are hiring a new position or new role into your organization in your perfect world you want somebody who's got all of the skills all of the experience to slam dunk and fit into your team but what you're going to run into the video with the mass retirement a lot of organizations are facing a silver tsunami they're looking at the retirement of older people and what's hurting them is knowledge walking out the door and the knowledge walks out the door because there is no useful repository of knowledge so one of the aspects with the complete set that works together is when you're using a consistent approach and a consistent methodology and a consistent repository is that you're able to interleave knowledge you're able to capture nuance and expertise at the same time as being able to bring people on board and as Nathan says well I can shadow you once and next time can I be involved and can I continue that development so that we can extend the work and extend that knowledge that's it for the questions Sam, Dave, Nathan thank you very much for this and let's see how we can help get the word out as well so thank you very very much thank you